iT邦幫忙

第 11 屆 iThome 鐵人賽

DAY 22
0
Software Development

後端攻城獅的實戰筆記系列 第 22

持續集成與持續交付 with Docker

  • 分享至 

  • xImage
  •  

前言

昨天的最後一句是,CD 混著環境一起講比較合理,所以重點就是環境這東西。因為 CI 只到打包,CD 是到部屬,一牽扯到環境,手法上就會有一些花樣可以討論。那麼今天貫穿主軸的 keyword 是 docker,我們開始囉!

Before We Containerize

還記得以前剛入行的時候整天抱著一台實體機在裝 Linux,然後依序裝上一堆服務之後,裝個 JRE,手動的把打包結果丟上去換版,後來厲害一點,把這個流程換成 bash 加強自動化流程。而到了雲時代,無論是私有或是公有,我們都已經鮮少碰到實體機,我們面向 VM,基礎設施的基底是虛擬機,換成熟知的公有雲就是 AWS EC2 或是 GCP GCE。

如果你部屬的單位是一台,手動還輕鬆寫意,如果你部屬的單位慢慢的變大,繼續手動下去可能會讓你回不了家 (誤)。基礎設施即代碼 (Infrastructure as Code) 在這個潮流之下誕生,無論是 Puppet、Chef、Ansible、Terraform、Vagrant、Packer 等等,都先後大紅大紫,有些紅到現在還在紅。透過代碼化加上工具一次控制多台 VM 變成輕鬆的一件事,你的 CD 基植於上自然如虎添翼,畢竟如果你可以更輕鬆的控制環境代表測試也能做的更輕鬆,無論是迴歸測試、冒煙測試、壓力測試等等。

Docker

那既然上面那麼棒,為什麼還有 Docker 竄出頭的機會?我覺得這跟他精準需求切入還有聰明設計有關。Docker 其實非常像 Vagrant,設計跟語法上就可以看到非常多相似的地方,下面舉三個例子。

Vagrantfile -> Dockerfile
$ vagrant package -> $ docker build
$ vagrant upload -> $ docker push

等於是說他吸收了 Vagrant 好的部份,同時解決了商用伺服器 Unix 商想解決的兩大問題 (heavy & slow),它解決 heavy 的方式是把 image 切成一層一層的,最大程度的覆用映像擋,大家在 docker push or pull 的時候應該都看過類似的。

再來是 slow 的問題,因為他根本一開始不處理 Windows 用戶,又設計了一套資源共用的架構,等於是一個 VM 裡面跑很多個 Container,輕而巧自然就快的起來,可以參考下圖。

在加上它借鏡 GitHub 也弄了一個 DockerHub,也組建了一個完整的生命週期,Infrastructure as Source、Image as Artifact 和Container as Instance。於是 Dev 不再只是關心 package 前,Ops 只關心 package 後,現在有了 Docker 連同環境一起包起來,一切變得更方便更靈活更快速,DevOps 和在一起工作,關注點一致,整個才能串在一起搞好 CI & CD。


About Me

Jian-Min Huang

wide range skill set backend engineer

Research, Architecture, Coding, DB, Ops, Infra.

mainly write Java but also ❤️ Scala, Kotlin and Go

http://github.jianminhuang.cc

http://linkedin.jianminhuang.cc

http://note.jianminhuang.cc

yfr.huang@hotmail.com


上一篇
持續集成與持續交付
下一篇
來小講微服務
系列文
後端攻城獅的實戰筆記30
圖片
  直播研討會
圖片
{{ item.channelVendor }} {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言